DevOps Overview BTech CSE Sem V · UPES Dehradun
Unit I · Lecture 3

Agile vs Waterfall
& Iterative Agile Development

A structured comparison of two paradigms — and a deep look
at how iterative development actually works in practice.

COURSE
DevOps Overview
UNIT
I of IV
LECTURE
3 of series
PREV. LECTURE
Dev vs Ops & Agile

Dr. Mohsin Furkh Dar  ·  School of Computer Science, UPES Dehradun

Overview

What We Cover Today

🔁 Recap
Quick recap of the Waterfall model and Agile values from Lectures 1 & 2.
⚖️ Head-to-Head
Structured multi-dimensional comparison — philosophy, delivery, risk, teams, change.
📐 When to Use Which
Decision framework — which methodology fits which type of project.
🔄 Iterative Agile
The mechanics of iteration: sprints, backlog, increment, feedback loops.
🏃 Sprint Deep-Dive
Inside a single sprint — roles, ceremonies, artefacts, daily rhythm.
📈 Value Over Time
How iterative delivery changes the risk-value curve compared to Waterfall.
Recap — Lectures 1 & 2

Where We Are in the Story

Waterfall (Lecture 1)

  • Sequential phases — Requirements → Design → Code → Test → Deploy
  • Each phase fully complete before the next begins
  • Requirements locked upfront — change is expensive
  • Customer sees product only at the end
  • Works for stable, well-understood domains

Agile Movement (Lecture 2)

  • Response to Waterfall's late-delivery failure mode
  • Manifesto (2001): 4 values, 12 principles
  • Individuals & interactions over processes
  • Working software over documentation
  • Customer collaboration & responding to change
Today's question: Beyond philosophy, how exactly do Agile and Waterfall differ across every dimension of a real project — and what does "iterative" actually mean in practice?
01

Agile vs Waterfall

A structured comparison across six dimensions

Comparison — Dimension 1 & 2

Philosophy & Project Structure

🌊 Waterfall — Philosophy

  • Engineering discipline model — build to a complete specification
  • Predictability and documentation are primary goals
  • Trust the plan; deviation = project failure
  • Success = delivered on time, on budget, to spec
  • Uncertainty is managed by thorough upfront analysis

⚡ Agile — Philosophy

  • Empirical model — learn by doing, adapt continuously
  • Customer value delivered early and often is the goal
  • Plans are a starting point, not a commitment
  • Success = customer satisfied with working software
  • Uncertainty is managed by keeping decisions reversible

🌊 Waterfall — Structure

  • Linear: one phase at a time, in fixed sequence
  • Gate reviews between phases — formal sign-off required
  • Long project horizon: months to years per release
  • All features planned and scoped at project start

⚡ Agile — Structure

  • Iterative & incremental: multiple short cycles
  • Each iteration self-contained: plan → build → test → review
  • Short horizon: working software every 1–4 weeks
  • Scope emerges and evolves through the project
Comparison — Dimension 3 & 4

Requirements & Response to Change

🌊 Waterfall — Requirements

  • Captured exhaustively upfront in an SRS document
  • Treated as a contract between customer and team
  • Assumed to be complete, correct, and stable
  • Changing a requirement triggers a formal change request
  • Cost of change grows exponentially the later it occurs

⚡ Agile — Requirements

  • Captured as user stories in a living product backlog
  • Deliberately kept at a high level until a sprint needs them
  • Expected to evolve — refinement is a continuous activity
  • Customer reprioritises backlog each sprint freely
  • Cost of change kept low by short iteration cycles

🌊 Waterfall — Change

  • Change Control Board reviews and approves changes
  • Impact assessed on schedule, cost, and scope
  • Often results in a formal project amendment
  • Late change typically means scope cut or date slip

⚡ Agile — Change

  • Changes welcomed — backlog simply reprioritised
  • New items added; lower-priority items drop out
  • No formal change request process needed
  • Responding to change = competitive advantage
Comparison — Dimensions 5 & 6

Teams, Testing & Risk Profile

Dimension 🌊 Waterfall ⚡ Agile
Team structure Specialised silos: analysts → designers → developers → testers Cross-functional teams own the full slice — design, code, and test
Testing Late After all code written; bugs expensive to fix Continuous Testing within every sprint; TDD common
Customer involvement At start (requirements) and end (acceptance) only Active participant throughout — sprint reviews every cycle
Risk timing Back-loaded Failure visible only at delivery Front-loaded Risks surface within the first sprint
Documentation Extensive, formal, mandated at each phase gate Just enough — serves the team; working software is primary evidence
Delivery rhythm One large release after project completion Potentially shippable increment every 1–4 weeks
Best fit Stable requirements, regulated industries, fixed-price contracts Evolving requirements, fast markets, innovation-driven products
Decision Framework

Choosing the Right Methodology

Choose Waterfall when…

  • Requirements are fixed, complete, and well-understood before start
  • Regulatory compliance demands comprehensive documentation
  • Fixed-price, fixed-scope contract — no room for scope flexibility
  • Hardware or physical systems involved (embedded, aerospace, civil)
  • Short project where a full iteration cycle adds no value
  • Large, distributed teams needing formal coordination

Choose Agile when…

  • Requirements are expected to evolve or are not yet fully clear
  • Customer needs early, frequent delivery of value
  • Market is fast-moving — time-to-market is a competitive factor
  • Innovation or R&D work where the destination is uncertain
  • Team is co-located or able to communicate daily
  • Product will be used by real users whose feedback shapes direction
Reality check: Most modern organisations use a hybrid — Agile development practices (sprints, user stories, CI) combined with Waterfall-style governance for programme-level planning and financial reporting. The key is knowing what each buys you.
02

Iterative Agile Development

The mechanics of build-measure-learn cycles
and how incremental delivery changes everything

Iterative Agile — Core Concepts

Iterative vs Incremental — Two Distinct Ideas

Iterative Development

  • Build something → evaluate → refine → repeat
  • Each pass through the cycle improves what exists
  • Analogous to drafting an essay: v1 → feedback → v2 → v3
  • Focus: improving quality and fit-to-need over time
  • Works even when the final shape is not yet known

Incremental Development

  • Build and deliver a portion of the product at a time
  • Each increment adds new, working functionality
  • Final product assembled from completed increments
  • Focus: delivering usable value as early as possible
  • Requires knowing what the parts are upfront
Agile is both: It is iterative — each sprint may revisit and improve earlier decisions — and incremental — each sprint adds working, tested functionality to the product. This combination is what makes Agile fundamentally different from both pure Waterfall and simple prototyping.
Iterative Agile — The Cycle

Inside a Single Iteration (Sprint)

↺
① Sprint Planning
Team selects user stories from backlog. Breaks each into tasks. Commits to a sprint goal. Time-box: 2–4 hours for a 2-week sprint.
Input
Product Backlog (prioritised)
② Daily Standups
15-minute daily sync. Three questions: What did I do yesterday? What will I do today? Any blockers? Keeps the team aligned in real time.
Cadence
Every day of the sprint
③ Development & Testing
Developers design, code, and test concurrently. Definition of Done (DoD) must be met: coded + tested + reviewed + integrated. No separate test phase.
Output
Working, tested code
④ Sprint Review
Team demonstrates the working increment to the Product Owner and stakeholders. Feedback gathered. Backlog updated with new insights. Time-box: 1–2 hours.
Feedback
Customer & stakeholder input
⑤ Sprint Retrospective
Team inspects its own process — not the product. What went well? What to improve? What actions to take next sprint? Drives continuous improvement.
Output
Process improvement actions
Iterative Agile — Artefacts & Roles

The Building Blocks of Iterative Agile

Key Artefacts

  • Product Backlog: Ordered list of everything the product needs. Owned by the Product Owner. Always evolving.
  • Sprint Backlog: Subset of items selected for the current sprint, broken into tasks.
  • Increment: The sum of all completed backlog items — must be in a "done" state, potentially shippable.
  • User Story: "As a [user], I want [feature] so that [benefit]." Keeps focus on value, not tasks.
  • Definition of Done: Shared agreement on what "complete" means. Prevents partial work being called done.

Key Roles (Scrum)

  • Product Owner: Prioritises the backlog. Represents the customer. Defines acceptance criteria.
  • Scrum Master: Facilitates ceremonies. Removes impediments. Coaches the team on Agile practice.
  • Development Team: Cross-functional group of 3–9 people who design, build, and test each sprint.
  • Stakeholders: Attend sprint reviews. Provide feedback. Do not direct daily work.
Transparency principle: Everything in Agile is visible — the backlog, the sprint progress (burndown chart), the definition of done. There are no hidden phases or surprise deliverables.
Iterative Agile — Business Value

How Iterative Delivery Changes the Value Curve

The most important business argument for iterative Agile: value is delivered continuously, risk is front-loaded, and course correction is cheap.
Waterfall
Requirements → Design → Build → Test → Deploy  (12–24 months)
Value delivered: once, at the very end
Sprint 1
S1
✅ First working feature delivered
Sprint 2
S1 → S2
✅ Second increment — feedback incorporated
Sprint 3
S1 → S2 → S3
✅ Backlog reprioritised after S2 review
Sprint N
Growing increment…
✅ Value delivered every 2 weeks throughout
💡
Early ROI
High-value features go into Sprint 1 — business starts seeing returns within weeks, not after years.
💡
Early risk
If the approach is wrong, you discover it in Sprint 1 — not after 18 months of investment.
Putting It Together

Scenario: E-Commerce Platform — Waterfall vs Agile

🌊 Waterfall Approach

  • Month 1–2: Full requirements for all 200+ features documented
  • Month 3–5: Complete system architecture designed
  • Month 6–14: All features built simultaneously by separate teams
  • Month 15–17: System testing — many integration failures found
  • Month 18: Launch — market has shifted; competitor launched 12 months ago
  • Post-launch: Critical features customers wanted were never on the original spec
  • Outcome: Over budget, late, and partially wrong

⚡ Agile Approach

  • Sprint 1 (Week 2): Product search and browsing live — real user feedback begins
  • Sprint 2 (Week 4): Checkout flow added — discovers UX problem early, fixed cheaply
  • Sprint 3 (Week 6): Payment integration — customer requests mobile-first layout, added to backlog
  • Sprint 4–6: Recommendations, reviews, mobile design — all informed by real usage data
  • Month 3: Fully functional v1 live. Competitor not yet ahead.
  • Ongoing: Product evolves based on real customer behaviour, not month-1 assumptions
  • Outcome: On time, right product, continuously improving
Lecture Wrap-Up

Key Takeaways & What's Next

💡
Not either/or
Waterfall and Agile are not good vs bad — they are tools suited to different contexts. Knowing when to use each is a professional skill.
💡
Change is the variable
The fundamental question is: how likely are requirements to change? High change probability → Agile wins. Stable requirements → Waterfall is defensible.
💡
Iterative = both
Agile is iterative (refine what exists) AND incremental (add new working functionality). The sprint cycle delivers both properties simultaneously.
💡
Risk inversion
Iterative delivery inverts the risk curve — you find out you are wrong in Sprint 1, not Month 18. This is the single strongest business argument for Agile.
💡
Sprint anatomy
Planning → Daily Standups → Development & Testing → Review → Retrospective. Every sprint is a complete miniature project delivering something real.
➡️
Next lecture
Deep dive into the four Agile Manifesto values: individuals & interactions, working software, customer collaboration, and responding to change.
DevOps Overview · Unit I · Lecture 3  ·  Dr. Mohsin Furkh Dar  ·  UPES Dehradun · Summer 2026
← → or swipe